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REMARKS/ARGUMENTS 

Favorable reconsideration of this application, in light of the following discussion, is 
respectfully requested. 

Claims 12, 14-16, 18, and 20-23 are currently pending. No claim amendments are 
presented, thus no new matter has been added. 

In the outstanding Office Action, Claims 12-14 and 20-23 were rejected under 35 
U.S.C. § 103(a) as being unpatentable over Mostafa (U.S. Pub. No. 2002/0073205) in view of 
Richardson et al. (U.S. Pub No. 2005/0021806, hereafter " Richardson "), Jason, Jr. et al. (U.S. 
Patent No. 6,728,243, hereafter " Jason "), and Barde et al. (U.S. Pub. No. 2004/0268400, 
hereafter " Barde "); and Claims 15-16 and 18 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Mostafa in view of Richardson , Jason , Barde , and Cooper (U.S. Pub. No. 
2004/0003399). 

With respect to the rejection of Claim 12 under 35 U.S.C. §103(a), Applicants 

respectfully traverse this ground of rejection. Claim 12 recites, inter alia, 

dividing the streaming video data into high 
prioritized data which are I-frames, and low prioritized data 
which are P-frames, wherein the high prioritized data are 
transmitted via a secure medium, and the low prioritized 
data are transmitted over a standard channel;. . . 

wherein the high prioritized data are transmitted via 
MMS and the low prioritized data are transmitted via 
streaming, and before a streaming service is initialized, an 
MMS notification message is initially transmitted to the 
terminal, the MMS notification message includes buffer 
data and information about the data flow, the buffer data 
being initial streaming video data that can be stored on the 
terminal prior to a user of the terminal starting a streaming 
service such that the streaming client can start streaming of 
buffer data without delay. 

Applicants submit that Mostafa , Richardson , Jason , and Barde fail to disclose or 
suggest all of the features of Claim 12. 
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Mostafa is directed to a communication service in which an MMS notification is sent 

to a receiving terminal prior to a terminal downloading media from a media server. Mostafa 

describes that in the conventional art, a Multimedia Message Service (MMS) message is 

constructed to contain media content, information necessary to describe the media content, 

and addressing information (see para. [0008]). Mostafa also describes that the MMS 

message must be downloaded as a whole and therefore the MMS message (including the 

media content) must be downloaded and stored in the receiving terminal before it can be 

presented to the user (see para. [0008]-[0009])). Mostafa also describes that "[t]he 

encapsulation of media content, message description and addressing information in a single 

entity as proposed in current MMS specifications is incompatible with the streaming of 

media content." (see para. [0014]). 

To overcome the limitations of MMS, Fig. 2 of Mostafa shows a system 20 which 

includes a communication server which includes a media server 22 and a MMS server 23. 

Mostafa describes a three phase process of streaming information to the receiving terminal. 

During phase 1, a sender 21 establishes a streaming session with media server 22 and uploads 

media content to the server (see para. [0103]). During phase 2, a notification is sent via the 

MMS server 23 to receiver 24 which indicates that the media content is stored on media 

server 22 (see para. [0104]). During phase 3, the receiver 24 establishes a streaming session 

with media server 22 based on information in the notification message and the receiver starts 

to download and play the media (see para. [0105]). 

However, Applicants emphasize that Mostafa explicitly does not describe that the 

streaming content being divided over two different channels. On the contrary, as described 

above, Mostafa describes that either the entire media content is encapsulated as a whole in an 

MMS message as in the conventional art, or as in the invention described by Mostafa , it is 

streamed separately through a media server. 
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Therefore, as acknowledged in the Office Action on page 5, Mostafa does not 

disclose or suggest "dividing the streaming video data into high prioritized data which are I- 

frames, and low prioritized data which are P-frames," and "wherein the high prioritized data 

are transmitted via MMS and the low prioritized data are transmitted via streaming. . as 

defined by Claim 12. 

Applicants note that the Office Action relies on Richardson to disclose "dividing the 
streaming video data into high prioritized data which are I-frames, and low prioritized data 
which are P-frames." 

Richardson is directed to a method of delivering data streams of multiple data types at 
different priority levels. Fig. 1 of Richardson shows a server 100 linked to a client 200 via 
networks 300, 500, and 400 (see para. [0016]). Richardson describes that server 100 can 
provide a video data stream comprising different types of video frames, such as I frames, P 
frames, and B frames (see para. [0016]). Richardson further describes that after the I frames, 
B frames, and P frames are separated, the I frames may be transmitted in association with a 
first TCP/UDP port number, and the P and B frames may be transmitted in association with 
one or more different TCP/UDP port numbers (see para. [001 8]). 

Therefore, while Richardson discloses dividing a video stream into I frames and P- 
frames, it only describes sending such frames over different TCP/UDP port numbers. 
However, as acknowledged in the Office Action, Richardson does not disclose or suggest 
that "the high prioritized data are transmitted via MMS and the low prioritized data are 
transmitted via streaming." On the contrary, Richardson does not explicitly disclose or 
suggest that either of the streams comprising I-frames or P-frames could be delivered over a 
mobile network, and Applicants note that MMS is a service standardized for mobile 
telecommunications. 
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Therefore, although Richardson discloses the general concept of dividing a video 
stream into I-frames and P-frames, the combination of at least Mostafa and Richardson does 
not disclose or suggest all of "dividing the streaming video data into high prioritized data 
which are I-frames, and low prioritized data which are P-frames," and "wherein the high 
prioritized data are transmitted via MMS and the low prioritized data are transmitted via 
streaming. . as defined by Claim 12. 

The Office Action had also acknowledged that Mostafa in view of Richardson , Jason , 

and Barde fail to disclose or suggest "wherein the high prioritized data are transmitted via 

MMS and the low prioritized data are transmitted via streaming. . (see Office Action, at 

page 8). To overcome this deficiency, the Office Action states the following on page 8. 

However, the practice of transmitting high priority 
data separately from low priority data, as well as the 
practices of transmitting data via MMS and streaming are 
commonly known in the art. Also the practice of first 
transmitting I-frames, which are the reference frames of 
any video, and are therefore essential to the reproduction of 
a video, is commonly known. The only difference is the 
combination of all of the practices together in a single 
system. By implementing streaming functionality within 
the framework of existing MMS protocol, a user is 
provided with complete flexibility to decide whether and 
when to receive and playback media content. 

However, as discussed above, Mostafa 's teaching of the MMS protocol explicitly 

indicates that streaming data cannot itself be sent within an MMS message because the whole 

message itself must be downloaded by the receiving terminal before the user of the receiving 

terminal can view the media content. It is because of these limitations on the MMS protocol 

that Mostafa' s solution is directed to using a MMS message for notification purposes while 

streaming the media content separately from MMS. Therefore, there is no teaching in the 

applied art at all to have the high prioritized data of a video stream transmitted via MMS as 

defined in Claim 12. 



5 



Application No. 10/564,065 

Reply to Office Action of June 25, 2009 

As stated in MPEP 2145.X.A: 

However, " [a] ny judgement on obviousness is in a 
sense necessarily a reconstruction based on hindsight 
reasoning, but so long as it takes into account only 
knowledge which was within the level of ordinary skill in 
the art at the time the claimed invention was made and 
does not include knowledge gleaned only from applicant's 
disclosure, such a reconstruction is proper." In re 
McLaughlin 443 F.2d 1392, 1395, 170 USPQ 209,212 
(CCPA 1971). (Emphasis added). 

Thus, Applicants submit that the Office Action has not properly shown why a person 
of ordinary skill in the art would transmit the high prioritized data of a video stream via the 
MMS notification message of Mostafa especially given Mostafa's description of the 
limitations of using streaming data within MMS. Therefore, it appears that the Office Action 
is using improper hindsight analysis based on the Applicant's disclosure to achieve the 
above-mentioned features of Claim 12. 

Therefore, Applicants submit that for at least the reasons discussed above, the 
rejection of Claim 12 under 35 U.S.C. § 103(a) is improper and must be withdrawn. 

Furthermore, as previously presented, it appears that the Office Action acknowledges 
that while Mostafa discloses an MMS notification message, it does not specifically disclose 
"the MMS notification message includes buffer data and information about the data flow, the 
buffer data being initial streaming video data that can be stored on the terminal prior to a user 
of the terminal starting a streaming service such that the streaming client can start streaming 
of buffer data without delay." (See Office Action, at page 6). The Office Action relies on 
Barde to remedy this deficiency of Mostafa (see Office Action, at page 6). 

Fig. 1 of Barde shows a network 100 with various client devices and server devices 
attached thereto. Fig. 2 shows that a client device has a streaming media player 200 with a 
buffer 206 and a "stitched-reference play-list" 208. The streaming media player is 
configured to buffer and play back streaming media content in accordance with the stitched 



6 



Application No. 10/564,065 

Reply to Office Action of June 25, 2009 

reference play-list 208 (see para. [0033]). Figs. 3-5 of Barde describe a prior art technique of 
downloading streaming media, in which a user selects a video to download via an interface 
shown on Fig. 3, and Fig. 5 shows that the media player will buffer data for about 5 seconds 
with a blank screen to show to the user. Then, after the buffering, the initial video content 
itself may just show a still image (such as an FBI warning) for several seconds before the 
remainder of the video is played (see Fig. 5). Figs. 6-8 show an embodiment of the invention 
described by Barde . Fig. 6 shows that when a user selects a video to be streamed, a still 
image (such as an FBI warning) is displayed almost immediately without the initial blank 
screen being shown while the video content is initially being buffered (see also Fig. 7). 

The Office Action had taken the position that it would have been obvious to include 
the initially buffered data of Barde ' s system in the MMS notification message of Mostafa ' s 
system for the advantage of implementing a quick starting video process within Mostafa ' s 
system, that, for example, may allow the user to preview the content sent as a way to further 
enhance the user's viewing at his/her own discretion. (See Office Action, at page 8). 

However, as Applicants previously presented, there is no teaching in the references to 
make this combination without using hindsight analysis based on the Applicants' disclosure. 
The MMS notification message of Mostafa is a message for notifying the availability of a 
streaming content, and as discussed above, Mostafa explicitly describes the then-known 
limitations to incorporating the streaming content into the MMS notification message. 
Given this description in Mostafa , Barde would have to explicitly describe including 
streaming video data in an MMS notification message in order for a person of ordinary skill 
in the art to disregard Mostafa 's description of the limitations of MMS and then include a 
portion of the streaming data in the MMS notification message of Mostafa . 

Notwithstanding, Applicants emphasize that Barde does not disclose or suggest 
including initially buffered data in the MMS notification message of Mostafa . 
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As previously presented, Barde describes a user first starting to stream the video data 

by selecting a video to be played, and then receiving a still (static) image to be displayed 

while video data is initially buffered. Thus, the user in Barde may be notified of the 

availability of a video by a playlist or an interface shown in Figs. 3 or 1 1 . However, Barde 

clearly describes that all buffering of data begins after the user actually selects the video for 

download, and thus after any notification of the availability of a video to a user has already 

been made, and after a user has started a streaming service (see for example, the time line of 

Fig. 7). 

In response to the Applicants' previous arguments, the Office Action states the 
following. 

"[t]he examiner believes that the reception of the 
static image of Barde's system is equivalent to a 
notification of video content to come, as the static image 
comes first, and is first displayed to the user before the rest 
of the video is displayed or even received. Via the user 
interface in Barde, the user is already notified only of video 
available to be streamed. As multiple videos are listed in a 
playlist, nothing is being streamed to the user, and therefore 
the only actual notification of the video being streamed is 
the static image, i.e., the message, being displayed to the 
user. 

Applicants emphasize that Barde discloses a user selecting a video to be downloaded 
and then initially receiving a still image to be displayed while the video data is initially being 
buffered. On the other hand, Mostafa describes sending an MMS notification message over 
an MMS server, which explicitly notifies a user that streaming video data is available to be 
streamed to the user over a separate media server. Additionally, the examiner's own analysis 
states that "[v]ia the user interface in Barde , the user is already notified only of video 
available to be streamed." Therefore, the static image in Barde does not notify the user of an 
available video as the MMS notification message of Mostafa does, because the user interface 
already achieves this purpose. The examiner also states that "therefore the only actual 
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notification of the video being streamed is the static image." However, it is not clear how 
this makes the static image of Barde the equivalent to the MMS notification message of 
Mostafa since the MMS notification message of Mostafa is sent prior to the streaming of the 
video rather than during the streaming of the video (see para. [0098] of Mostafa ). 

Thus, the mere transmission of the static image in Barde , which is clearly used for the 
purposes of preventing a blank screen from being shown while a user waits for video data to 
be buffered, does not disclose or suggest at all to modify the MMS notification message of 
Mostafa to include initially buffered data of the streaming video data. Applicants emphasize 
that the static image in Barde is clearly different in form, function, and timing than the MMS 
notification message of Mostafa . Therefore, Applicants' the static image initially sent in 
Barde is not the equivalent of an MMS notification message in Mostafa as asserted by the 
examiner. 

Therefore, Applicants respectfully submit that the combination of Mostafa and Barde 
fails to disclose or suggest "before a streaming service is initialized, an MMS notification 
message is initially transmitted to the terminal, the MMS notification message includes 
buffer data and information about the data flow, the buffer data being initial streaming video 
data that can be stored on the terminal prior to a user of the terminal starting a streaming 
service such that the streaming client can start streaming of buffer data without delay," as 
defined by Claim 12. 

Jason, and Cooper have also been considered but fail to remedy the deficiencies of 
Mostafa , Richardson , and Barde with regard to Claim 12. 

Therefore, Applicants respectfully submit that Claim 12 (and all associated dependent 
claims) patentably distinguishes over Mostafa , Richardson , Jason , Barde , and Cooper , either 
alone or in proper combination. 
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Independent Claims 20-22 recite features similar to those of Claim 12 discussed 
above. Therefore, Applicants respectfully submit that Claims 20-22 (and all associated 
dependent claims) patentably distinguish over Mostafa , Richardson , Jason , Barde, and 
Cooper , either alone or in proper combination. 

With respect to previously added Claim 23, Claim 23 recites, inter alia, 

the MMS notification message being sent to the 
terminal prior to the user of the terminal requesting to start 
a streaming session for receiving the video data. 

The Office Action takes the position that Mostafa in view of Richardson , Jason , and 
Barde discloses the MMS notification message being sent to the terminal prior to the user 
requesting to start a streaming session for receiving the video data (see Office Action, at page 
9, citing para. [0098] and [0107] of Mostafa ). However, in order to achieve all of the 
features of independent Claim 12, the Office Action interpreted the static image described in 
Barde as being equivalent to the MMS notification message of Mostafa . However, the static 
image in Barde is clearly sent to the terminal after a user requests starting a streaming 
session for receiving video data. Therefore, the static image in Barde cannot correspond to 
an "MMS notification message" as further clarified in Claim 23, and therefore the examiner's 
reliance on Barde for the features of independent Claim 12 in conjunction with dependent 
Claim 23 is improper. 

It appears that in addressing Barde's application with regard to Claim 23, the Office 
Action states the following: 

Furthermore, because the streaming of the actual 
video is not started until after the static image, i.e., the 
message, of Barde's system is displayed, it is reasonably 
taught that buffer data, in this case the static image 
message, is sent to the terminal prior to the start of the 
actual streaming service. (Emphasis added). 

However, Claim 23 does not merely recite that the MMS notification message is sent 

to the terminal prior to the start of the actual streaming service. Claim 23 recites that "the 
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MMS notification message being sent to the terminal prior to the user of the terminal 
requesting to start a streaming session for receiving the video data." Therefore, Applicants 
submit that the Office Action has not addressed how Barde's static image is sent to the 
terminal prior to the user of the terminal requesting to start a streaming session for receiving 
the video data so that it is the equivalent of the claimed "MMS notification message." 

Therefore, Applicants submit that dependent Claim 23 patentably distinguishes over 
Mostafa, Richardson , Jason , Barde, and Cooper , either alone or in proper combination, in 
addition to the reasons discussed above with regard to independent Claim 12. 

Consequently, in light of the above discussion and in view of the present amendment, 
the outstanding grounds for rejection are believed to have been overcome. The present 
application is believed to be in condition for formal allowance. An early and favorable 
action to that effect is respectfully requested. 
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